Each player needs to send out a `heartbeat' if they haven't sent a
packet for 5 seconds, so other players know they're still online. 
   Maybe it should check through all the unacknowledged packets for one 
that's overtime, rather than just the oldest one, as it does at the 
moment.

  I need to improve the code to test wether the game is running in NTSC or
PAL. Also, some of the time-sync code could be made more robust by 
checking the standard deviation of the lags.

   Finish changing the last few string handling routines to Peeking/Poking
to speed up the routines. The string (in a newtype) which holds the
reliable message sent, has to be changed to a buffer, and the
Security_Warning{} and Comms_Debug{} routines have to be changed so they
return a constant or a pointer to a buffer, instead of a String.

   I'll have to put in checking routines, to make sure all packets are
received in order- as you wouldn't want to execute packet 2, and then
packet 1 (if 1 had to be resent), so I'll have to buffer the incoming
packets until the earlier packet is resent- this is why Quake gets lagged
badly if you have a bad connection (lots of lost/broken packets). Also
putting all incoming packets into a buffer will allow me to do what Quake
does, in that all single-player movements (the person playing on that
machine) are put into the buffer as well, and then they're executed the
same as the movements from the other players. 

  I'll add routines so you can either send messages by Peer-to-Peer, or by
Client-Server, or both in the same game if you wanted. Also, with reliable
messages you will be able to make sure the packets are received in the
correct order at the other machine- any lost/slow packets are waited for
first before the later packets are passed to your game. Or you can have
packets sent without the order they are received mattering for speed (like
power-ups, system messages etc.

  I have to get it to check wether any incoming packets have been dropped,
and ask for a resend, rather than just the sender checking- this will
speed up some resends. 
    
 Data from the player at your machine, will be put into the incoming data buffer
and will be delt with the same as the other player's (ie: the single-player data
will be handled the same as the multi-player). This way we can put an
artificial lag into the player's movements when using Peer-To-Peer, to
prevent there being too much of a discrepancy in a player's position on
different machines if you have higher lags.

  The Connection routine needs improving, allowing for large data transfers,
for things like `Skins' (player appearance) (needed to be transfered
before game starts), and non game critical data like `Taunts' (samples
to be triggered by another player) etc, which can be transfered after login
by trickle feed (so as not to take up too much bandwidth).  

  I have to change the `player honesty' system (if a player loses
connection with another player when the rest haven't), as it could be got
around with packet filtering- I would just send the messages with the
Client-Server protocol instead between those two players.

  For Client-Server routines I'll make a `packet gathering' routine for
the Server, so it'll gather packets on one frame and send them all out
together in one packet on the next frame, so at 50 fps, the Clients would
never receive more than 2 packets per frame, no matter how many players
there were in the game.   
 
  Also, later I'll make a game connection program using the OrionIRC source,
so you could find other people on IRC, click on a person's name who's 
acting as a game Server, and click on the appropriate game button to log
into the game.

  I need to convert the routines to C or assembler, so I can create an Amiga
shared lib.